Electronic mail, or email, has become a ubiquitous element of modern communications. Many credit the explosive growth of the Internet, and internal corporate networks, to the ability of people to communicate and work together through email. In an effort to ensure that email from many different computing platforms can be seamlessly exchanged among the platforms, standards have been developed defining the structure of email messages, and the protocols and mechanisms used to transport and deliver those messages.
One standard for governing the transmission of email messages is known as the Simple Mail Transfer Protocol, or SMTP. SMTP defines a series of commands that computing devices can use to transfer email messages from one computing device to another. Generally, SMTP allows two computing devices to establish a two-way transmission channel to transfer one or more pieces of mail in three basic steps. A first step can transfer information regarding the sender of the email message, a second step can transfer information regarding the intended recipients of the email message, and a third step can transfer the actual contents of the email message itself.
Because of the distributed nature of networks, including the Internet, SMTP contemplates that a single email message from a sender to a recipient may be transmitted in the above described manner multiple times between intermediate host computing devices. When an intermediate host computing device receives an email message for further transmission, it can initiate another SMTP channel with a further computing device and conduct a similar transfer. However, once the email is received at its final destination, the contents of the email message can be presented to a user through an email reader program or the like.
To further ensure the seamlessness of email messages as they are exchanged between platforms, the structure of the mail data itself can also be standardized. One standard for the structure of email messages is known as the Internet Message Format. The Internet Message Format divides mail data into lines of characters having a maximum length. An email message can comprise header fields and a body containing the text or other data that one user wished to transfer to other users. The header fields can be composed of a field name and a field body. Commonly recognized field names include the TO, FROM, DATE, CC and BCC. While such fields may contain similar information as is transferred between computing devices via an SMTP channel, the header fields are visible to readers of the email message, while the information transferred as part of the first two steps of an SMTP transfer can be exclusively used by mail transferring programs.
Of particular concern can be the treatment of the recipients listed in the BCC field. The BCC field, or “blind-carbon-copy” field, is intended to provide email senders a mechanism by which they can send email messages to certain individuals without allowing other recipients of the same message to know that those individuals received a copy. For example, senders may wish to protect the identity of certain recipients or they may wish to protect the email address of certain recipients. Therefore, while all of the recipients BCCed on an email message can appear, in the form or an email address, as one of the arguments transferred with an SMTP RCPT command, those same recipients may not appear in the BCC header field of the email data sent to other recipients.
Three possibilities are defined for protecting the identity of recipients listed as BCCed on an email message. Prior to transmitting the email, the sending computing device can remove the BCC header from the email data and then transmit the message to all of the recipients. Alternatively, the BCC header can be removed only from the email data sent to the recipients listed in the TO and CC header fields, while the recipients listed in the BCC header field can receive an alternative email data containing the BCC header field. A third defined possibility allows the transmission of a blank BCC header field to all of the recipients.
As can be seen from the above description, an email message can be represented as an envelope of data, with the envelope containing information regarding the sender and recipients of the data, and the data containing header information and additional data intended for the recipient. Protocols such as SMTP can define a transfer mechanism for the envelope, including the sender and recipient information, and protocols such as the Internet Message Format can define an interpretation mechanism for the data contained in the envelope.
However, neither SMTP nor the Internet Message Format provide protection against tampering. Thus, a malicious user or computing device could intercept email messages, and alter their contents. To prevent such tampering, a secure encoding scheme, such as S/MIME can be used. The Multipurpose Internet Mail Extensions (MIME) encoding scheme establishes a common mechanism by which any data can be transferred by the above described protocols. Specifically, the MIME encoding scheme allows data to be encoded into a text-based format, and provides headers which can specify the type of data that is encoded, to aid in the decoding of the data by the recipient.
The Secure Multipurpose Internet Mail Extensions (S/MIME) encoding scheme can be used with the Cryptographic Message Syntax (CMS) to provide mechanisms by which the content of an email message, including any MIME encoded data contained within the message, can be encrypted in such a manner that each recipient listed in the headers of the message receives the encrypted data and an encryption key encrypted specifically for that recipient. This encrypted data can then either be attached to a part of the message that is not encrypted, together with MIME headers specifying the encryption of the data, and the email message headers. Such an encrypted email message can then be transmitted through ordinary message transmission algorithms, such as SMTP, while protecting the contents of the email message from malicious attacks.
The combination of S/MIME and CMS can sign data and encrypt data in various combinations to protect the content of an email message. For example, a textual message that is to be sent securely using the S/MIME encoding scheme can first be converted to a canonical form that is representable on both the sending and receiving computing platforms. Once converted, it can be signed, and then the signed data can then be further encrypted for each recipient and packaged. This package can then be placed in an email message, having appropriate headers, which can further be transmitted in an envelop according to SMTP, as described above. Upon receipt by each of the recipients, the email message can be opened, the data can be unencrypted, and its integrity can be verified. In such a manner an email message can be protected during transit.
However, while S/MIME can provide for the protection of email contents, the existence of recipient-specific information in S/MIME data formats can reveal the identity of recipients that were only BCCed on the email message, even if the BCC field is removed from the header of the email. Specifically, the content of an S/MIME email message is individually encrypted for each recipient, including the recipients listed in the BCC field. Thus, even though the header may have had all BCC information removed as described above, certificate identifiers and other recipient-specific information, including information specific to BCC recipients, can still be found in an unencrypted form as part of the encrypted email package. Consequently, by merely referencing this unencrypted, recipient-specific information, the identity of all recipients, including BCC recipients can be determined by any recipient.